前言：基線是「能描述、能比對」的狀態

Day 10 的環境移植，是在一台已經執行過數個實驗配方的 GB10 節點上進行。Engram 分片直接取用本機既有檔案，驅動程式版本為 580.178.04，與原始配方作者採用的 580.173.02 存在微小落差，這兩處在先前都被歸類為「未受控變因」。這些變因之所以失去控制，根本問題在於缺乏一份精確記錄伺服器當前組態的基準文件，導致實驗過後無法明確回答「系統環境究竟變更了哪些設定」。

為 GB10 建立節點基線（Baseline）正是為了徹底解決組態漂移問題，概念與 GCB 或主機標準組態規範完全一致。這個工程實作包含兩個核心部分：第一部分是標準化設定，將兩台 DGX Spark 調整至完全一致且可精確描述的狀態，涵蓋帳號、SSH、套件版本、網路配置與儲存掛載，第二部分則是狀態快照機制，透過自動化腳本將底層狀態輸出為純文字檔案，藉由比對兩台節點之間或單一節點變更前後的 diff 差異，精準掌握組態漂移並留下異動註記，提供後續維運團隊追蹤。系列後續關於 Day 12 的守護行程、Day 19 的監控指標與 Day 26 的變更管理單，全數以這份快照作為驗證對象。

本日實作的程式碼收錄於開源專案 spark-baseline，結構包含快照擷取腳本、sshd 加固 drop-in 設定檔，以及防範管理者誤把自己鎖在門外的套用腳本。快照腳本已在兩台 DGX Spark 節點以一般使用者權限完整驗證，共產出 37 份基準檔案，需要 root 權限的三個特定檢查區塊則依防禦性架構設計主動跳過並留下稽核標記。

文中所使用的系統加固程式碼已在 Ubuntu 24.04 容器環境進行情境驗證，其 OpenSSH 版本與 DGX OS 內建版本完全一致，五種邊界異常狀況皆符合防禦預期，DGX OS 的底層細節則嚴格參照 NVIDIA DGX Spark 官方維護手冊與雙機現場實測資料。

一、基線包含什麼

所有檢測項目外加一份 99-summary.txt，用以記錄快照擷取時間點與因權限跳過的段落。所有檔案皆為純文字格式，完全由既有系統原生指令產生，腳本僅過濾具備時間變動特性的動態欄位，不進行任何非必要的自訂文字解析。維持原始輸出是為了避免解析邏輯隨腳本改版而失效，確保數年之後系統管理員依然能直接以原生 diff 工具進行版本對比。整份基線工程在資安防護框架上，精確對應 ISO/IEC 27001:2022 控制項 A.8.9 組態管理（Configuration Management）。

在資安最小揭露原則下，快照設計刻意排除三類敏感資訊。私鑰與所有形式的憑證檔案絕對不寫入快照，授權金鑰的內容本體亦不記錄，32-authorized-keys.txt 僅擷取金鑰型別與註解文字，公鑰清單若完整揭露「特定人員之何種金鑰具備何主機登入權限」，本質上仍屬內部機敏情報，應留待管理人員登入伺服器現地審查。此外，主機硬體序號同樣予以遮蔽，/etc/dgx-release 內的 DGX_SERIAL_NUMBER 會在 00-identity.txt 處理過程中自動抹除。即使已做去敏處理，快照內仍含有帳號名稱與內部私有 IP 位址，存放快照的 Git 儲存庫必須設置為私有存取權限。

二、DGX OS 初始設定的順序

DGX Spark 出廠搭載 DGX OS，以 Ubuntu 24.04 LTS 為基礎底層，目前兩台機器均升級至 24.04.5，並由 NVIDIA 封裝專屬核心、GPU 驅動程式、CUDA 工具包與私有套件庫。DGX OS 的版號記錄於 /etc/dgx-release，出廠預設為 7.2.3，每次完成 OTA 更新即在檔尾追加一筆紀錄，目前版本推進至 7.6.0，核心為 7.0.0-1019-nvidia，驅動程式對應 580.178.04。官方手冊標明主要維護更新通常落於每年二月與八月。首次啟動時系統會引導建立本機帳號，無論透過實體外接螢幕或經由區域網路瀏覽器設定，底層均為同一初始化流程。

完成開機引導後，首要任務是將首次開機所建立的使用者定義為緊急救援帳號。該帳號嚴格限制僅能於本機主控台（Console）登入，不得開啟 SSH 遠端連線權限，帳號名稱應避免使用 nvidia、admin、dgx 等常見預設字詞。

接續進入系統升級作業，此時應一次性完成全部套件升級並停留在該版本。官方建議透過 DGX Dashboard 操作更新，若採指令模式則執行系統完整升級與韌體更新，完成後立即將主機重新開機，並執行首次基準快照。此時產出的快照代表「出廠最新狀態」，作為未來所有環境比對的基準原點。在實務維運中，升級後維持版本凍結是絕對重點，由於 DGX OS 更新源自 NVIDIA 官方套件庫，驅動程式與 CUDA 常伴隨大版本跳號，微小的驅動程式版本差異便足以導致分散式運算流程產生不可預期的偏差。

基礎系統就緒後，接著建立正式維運專用帳號，配置對應群組並匯入個人 SSH 公鑰，自此所有管理連線皆強制改走 SSH 通訊協定。隨後匯入強化版 SSH 組態，並依序完成核心與驅動套件的版本鎖定作業。

在網路架構配置上，DGX OS 的網路堆疊全權交由 NetworkManager 管理，/etc/netplan/ 僅保留將 renderer 指定至 NetworkManager 的設定，其餘介面組態均為 NetworkManager 自動產生的設定檔。因此，網路綁定必須使用 nmcli 工具操作，切勿手動撰寫 netplan。10GbE 介面配置專屬固定 IP 連接交換器，100GbE 介面則配置於另一獨立網段進行雙機直連，並將 MTU 調整為 9000。RoCE 高速傳輸無須額外安裝 OFED 驅動，其網卡驅動 mlx5_core 已整合於系統核心，使用者空間的 rdma-core 套件亦於出廠時完成安裝，設定時需注意 ConnectX-7 單一實體連接埠於系統中會呈現兩個網路介面，僅能擇一配置 IP 位址。

網路就緒後，將遠端 NFS 模型資料庫掛載設定寫入 fstab。最後部署系統守護程式與監控指標收集器，這兩組自研程式為節點上唯二允許常駐的非原生服務。全部就緒後再次執行系統快照，產出「基線 v1」版本，此時兩台節點的差異將僅限於識別碼與實體網路介面位址。

三、帳號與 SSH 加固

雙節點雖置於內部專屬 VLAN、不直接暴露於外部網際網路，但 SSH 作為唯一遠端管理入口，資安目標必須落實「特定白名單人員、全金鑰認證、最小授權管理」。

sshd 的 drop-in 設定機制

加固組態 10-hardening.conf 部署於 /etc/ssh/sshd_config.d/ 目錄，設定內容如下：

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
AllowGroups sshusers
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding local
PermitEmptyPasswords no

設定檔檔名前綴 10- 具備決定性排序意義。Ubuntu 原生 sshd_config 在設定檔起始處即宣告讀取目錄內所有 .conf 檔案，drop-in 規則依照字母順序載入，同一個參數以首次宣告之數值為準。因此，命名排序在前的 drop-in 不僅能覆蓋系統主設定檔，也能壓制後續載入的組態。部分雲端環境映像檔常內嵌優先權較低的設定並重新開啟密碼登入，DGX OS 7.x 預設該目錄為空且停用了 cloud-init，採用前綴命名能確保未來即便引入其他第三方套件，加固參數依然維持最高優先權。確認參數是否生效應使用 sshd -T 印出最終生效值，快照中的 34-sshd-dropins.txt 則保存主設定與所有 drop-in 的檔案雜湊值，無須 root 權限即可精準檢驗組態是否遭受竄改。

組態中的 AllowGroups sshusers 為最核心的權限防線，也是最容易因疏失導致自我阻斷的設定。使用者若未被明確加入該群組，即使金鑰驗證正確亦無法連線，因此自動化套用腳本在重載服務前會進行嚴密防呆校驗。

將 AllowTcpForwarding 設定為 local 而非全然關閉（no），是考量 DGX Dashboard 預設僅監聽本機端點 127.0.0.1:11000，維運端需仰賴 ssh -L 通道轉發進行存取，VS Code 遠端開發連線亦依賴此機制。全面封鎖將導致官方圖形管理與更新介面無法運作。設定為 local 能在維持本地轉發能力的同時，徹底關閉反向穿透節點的 ssh -R 機制。經容器驗證，本地轉發存取 Dashboard 正常，反向通道則會被主機即時阻擋。

防自我阻斷的套用腳本

加固腳本 harden-ssh.sh 具備完整的防禦檢驗機制。執行初期會確認目標管理帳號存在且其 authorized_keys 中已包含有效公鑰，若無則中斷作業。隨後系統建立 sshusers 群組並將管理帳號納入，接著備份既有設定並安裝加固 drop-in。在套用前，腳本會全面掃描其他設定檔中是否存在衝突的密碼或 root 登入宣告，並調用 sshd -t 檢查語法，若語法錯誤即立刻還原原始設定並退出。進一步透過 sshd -T 檢驗實際生效值，一旦確認密碼認證未徹底關閉，系統會主動復原檔案並停止變更，防止無效組態留滯於主機中引發重開機連線中斷。

在確認全數條件無誤後，腳本發出重載指令。為確保既有連線不受干擾，系統以重載（Reload）取代重啟（Restart）。考量 Ubuntu 24.04 採用 socket activation 機制管理 SSH，腳本透過 systemctl try-reload-or-restart ssh.service 安全觸發，使新建立的連線即刻套用全新資安防禦參數。

此套保護流程經 Ubuntu 24.04 容器完整驗證，精準涵蓋管理帳號缺乏金鑰、drop-in 語法毀損、覆蓋無效設定還原，以及多重驗證機制切換等邊界情境，確保權限群組外的連線一律被拒。

帳號權限管理標準

由於加入 docker 群組在實質權限上等同於取得 root 控制權，維運人員納入該群組是為了日常容器除錯與環境檢視所需，然而，後台常駐的監控與健康檢查服務僅需存取 GPU 狀態與記憶體資訊，嚴格禁止加入該群組。

本架構實踐嚴格對應 ISO/IEC 27001:2022 控制項 A.5.15 存取控制、A.5.18 存取權限、A.8.2 特權存取權限以及 A.8.5 安全鑑別。在資安稽核實務中，快照產出的 30 至 35 系列檔案即為最直接的技術符合性佐證。

防火牆配置與容器邊界

DGX OS 雖內建 ufw 工具，但出廠組態為未啟用狀態。啟用後應採取預設全數阻擋連入策略，依來源網段逐項放行。SSH 僅開放管理 VLAN 存取，推論服務通訊埠限定應用伺服器位址連線，監控採集埠僅允許中心端主機抓取，兩台節點間的 100GbE 直連網路介面則互相全面放行。

在網路防禦架構中必須特別注意 Docker 的運作特性。容器以 -p 參數發布通訊埠時，Docker 內部會藉由專屬 iptables 規則優先放行流量，此機制完全繞過標準 UFW 阻絕規則。針對此類服務，必須強制將通訊埠綁定於內部特定 IP 位址，或於 DOCKER-USER 鏈進行來源限制，若容器採用 host 網路模式，則其流量回歸標準 UFW 規則管制。快照中的 45-ufw.txt 會完整留存防火牆狀態，作為節點通訊邊界驗證依據。

四、版本鎖定延伸到節點

維持分散式環境一致性，必須將映像檔 Hash 鎖定原則全面延伸至作業系統實體層。以下四類核心元件必須實施強制版本鎖定：

在執行鎖定時，切忌盲目將所有 nvidia-* 套件進行 hold 標記。DGX OS 內部含有大量與驅動分支無關的原生設定套件，包含套件庫憑證金鑰、系統組合描述等，過度鎖定將導致基礎系統修補中斷。在標準環境中，鎖定規則會精確篩選出真正與執行環境高度相關的套件，將其收斂至 94 個關鍵項目並寫入快照中的 21-dpkg-pinned-candidates.txt。進行雙機環境比對時，該檔案為首要檢視對象。

系統預設未安裝自動無人值守更新套件，開機時僅仰賴單次性檢查服務確認運作中的核心與驅動模組版本相符，其餘系統升級均仰賴管理者手動發起。若需透過 DGX Dashboard 進行官方 OTA 系統升級，必須遵循嚴格的解鎖與重鎖作業程序。由於 Dashboard 底層透過 apt 進行全系統套件升級，遭鎖定的套件在升級過程中會被略過，極易產生周邊組件已更新、但核心與驅動程式仍留於舊版的不一致現象。

正確的升級程序必須先自快照的候選清單中讀取套件名稱，執行 unhold 確認鎖定清單完全清空。接著於管理端建立 SSH 本地通道連往 Dashboard 網頁介面，依照標準流程推動更新。更新完畢節點重開機後，維運人員應再次登入產出新版快照進行比對，並依據新快照的候選清單重新執行套件 hold 鎖定，將完整操作紀錄歸檔為正式變更紀錄單。

五、兩台怎麼整成一樣

將兩台節點進行基線對齊的方式，是分別執行快照擷取腳本並利用 diff -r 進行全目錄比對。在系統架構設計上，因硬體本質不同而必然產生差異的項目僅有六個檔案，包含主機識別名稱、實體網路 IP 與 MAC 位址、路由表、磁碟 UUID，以及維運團隊授權金鑰清單。除上述項目外，任何呈現在快照中的差異皆屬組態漂移，必須逐項查明原因並調整至一致。

為確保比對結果精確有效，快照機制主動排除了具備自發性變動特性的系統資料。快照不記錄動態程序識別碼（PID）、暫時性網路通訊埠、儲存空間動態使用量、GPU 即時溫度，亦排除 snap 相關動態掛載單元。過濾背景雜訊是為了確保管理者在執行比對時，視野不會被龐大的動態資料淹沒，進而精確捕捉到真正的環境偏差。

在實體雙機首次比對實測中，以一般使用者權限產出 37 份基準檔案，兩台機器扣除先天差異後，共計抓出九項非預期組態漂移：

• 套件清單（20、21）：兩台共通套件之版本完全一致，但主力節點因先前實驗遺留 202 個額外套件（包含 GPUDirect Storage 相關模組），次要節點則殘留了舊版 6.11 核心與前代驅動韌體套件。
• 軟體來源庫（23）：主力節點多出一組第三方 APT 來源清單。
• 常駐服務與連接埠（46、60、61）：主力節點開放了推論服務埠、遠端桌面與模型庫 automount，次要節點則多了一組開機自動啟動的 iperf3 伺服器。
• 容器環境（63、64）：雙機之 Docker 映像檔數量（29 對 4）與容器運行數量（3 對 1）呈現未對齊狀態。
• 排程設定（65）：主力節點包含重開機守護與每日健康巡檢腳本，次要節點排程全空。

此外，系統識別紀錄更揭露出兩台機器的出廠映像版本差異，主力機保留了歷史版本升級軌跡，次要機出廠時則直接跳過舊版。此類「無人知曉為何留滯」的舊核心與殘餘服務，正是未受控環境的典型特徵。唯有透過快照逐一將這些設定移除並對齊，兩台主機才能被視為具備同等能力的運算節點。

雙機平行更新程序

在建構 Tensor Parallelism（TP=2）的模型平行推論架構下，兩台節點共同乘載同一組模型運算，節點間極度依賴 NCCL 進行 RoCE 高速通訊。系統核心、GPU 驅動或通訊函式庫只要存在版號微調，就可能引發通訊逾時或效能資料失真。因此，雙機更新必須以「配對」為單位同步推動。

1. 鎖定維護時段：在同一維護窗口先關閉雙機上的對外推論服務，各自跑一次基線快照存檔。
2. 解除版本鎖定：雙機同步解除 apt-mark hold，並確保採用相同的升級途徑（統一透過 DGX Dashboard 或統一走命令列）。
3. 無間隔接續升級：雙機應在數分鐘內接續執行更新，避免 APT 套件庫因上游版本滾動而拉取到不一致的相依版本。
4. 驗證與比對：重開機後各自重新產生快照，嚴格比對 GPU 驅動、CUDA、核心、鎖定候選清單及 DGX OS 版本，確認全數相符才將服務上線。
5. 版本偏差對齊：若發生不一致，以通過驗證之節點為基準，將落後節點參照目標清單進行精準補丁：

awk -F'\t' 'NR==FNR {want[$1] = $2; next} ($1 in want) && want[$1] != $2 {print $1 "=" want[$1]}' \
    A/21-dpkg-pinned-candidates.txt B/21-dpkg-pinned-candidates.txt \
    | xargs sudo apt-get install --simulate

確認 --simulate 模擬執行無誤後，正式執行更新，若套件庫已無舊版本，則反向將另一台推升至最新版。
6. 重置基線鎖定：雙機重新套用 apt-mark hold，產出全新快照並提交至私有 Git 儲存庫，作為日後變更管理與稽核軌跡的依據。

實作驗證與常用指令

擷取系統基線快照作業，預設產出包含 37 個純文字組態檔與一份整體摘要：

git clone https://github.com/ivanusto/spark-baseline && cd spark-baseline
./baseline-snapshot.sh            # 輸出至 baseline/<主機>/<UTC 時間戳>/
cat baseline/*/*/99-summary.txt   # 檢查是否有未預期的跳過區塊

執行 SSH 資安加固作業，指令中帶入專屬管理員帳號以維繫存取權限，套用後應保持現有連線，另開視窗進行金鑰驗證與密碼阻斷測試：

sudo ADMIN_USER=$USER ./harden-ssh.sh
# 請勿關閉既有視窗，另開終端機進行雙向驗證：
ssh <主機>                              # 應以金鑰成功登入
ssh -o PubkeyAuthentication=no <主機>   # 應直接被拒絕連線，不出現密碼提示

跨節點或單一主機不同時間點之組態漂移檢視指令：

diff -r baseline/spark-a/20260924T120000Z baseline/spark-b/20260924T120500Z | less
diff -r baseline/spark-a/20260924T120000Z baseline/spark-a/20261001T090000Z

核心套件鎖定作業，直接取用快照產出的候選檔案名稱批次套用：

cut -f1 baseline/<主機>/<時間戳>/21-dpkg-pinned-candidates.txt | xargs sudo apt-mark hold
apt-mark showhold

熱與統一記憶體的守護

Day 12 將聚焦於熱能擴散與統一記憶體管理。在標準基線底定後，節點在長時間處於滿載極限下，主要面臨兩種典型系統崩潰情境：散熱飽和後觸發韌體防護強制斷電，以及統一記憶體耗盡造成主機失去響應僅剩 Ping 封包可達。gb10-ops 所設計的取樣器與守護行程正是專門用以監控並阻絕此類系統災難。所有警戒門檻值皆經過嚴格硬體壓力實測，後續將深入解析具體調校數據、組態配置，以及標準容器記憶體限制機制為何無法直接套用於此硬體架構之根本原因。

系列文章與專案原始碼：onprem-ops-30days

本日實作程式碼：spark-baseline v0.1.0

參考資料：

• NVIDIA DGX Spark 官方維護指南（包含 Initial Setup, First Boot、DGX OS 與 OS and Component Update Guide 系列技術文件）
• OpenSSH sshd_config 線上手冊（drop-in 配置排序規範與 AllowGroups 機制說明）
• Ubuntu 官方社群維護手冊（無人值守自動更新與 apt-mark hold 互動機制）
• ISO/IEC 27001:2022 資訊安全管理系統標準附錄 A 控制項（A.5.15 存取控制、A.5.18 存取權限、A.8.2 特權存取權限、A.8.5 安全鑑別、A.8.9 組態管理）